CVE-2026-46165
openvswitch: vport: fix self-deadlock on release of tunnel ports
Description
In the Linux kernel, the following vulnerability has been resolved: openvswitch: vport: fix self-deadlock on release of tunnel ports vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here. However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal. Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released.
INFO
Published Date :
May 28, 2026, 10:16 a.m.
Last Modified :
June 10, 2026, 9:14 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | MEDIUM | [email protected] |
Solution
- Move RCU call before unlock.
- Ensure RCU callback execution.
- Free the vport correctly.
- Release the device reference.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-46165.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-46165 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-46165
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-46165 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-46165 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Jun. 10, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE CWE-667 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:7.0:-:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.1.168 up to (excluding) 6.1.175 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.12.80 up to (excluding) 6.12.88 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.18.21 up to (excluding) 6.18.30 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19.11 up to (excluding) 7.0 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.6.131 up to (excluding) 6.6.140 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 7.0.1 up to (excluding) 7.0.7 Added Reference Type kernel.org: https://git.kernel.org/stable/c/366c482965c673565ecb8bcfb15d5548f13a6a10 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/3df75fff46b1517eb479d8e6b8e3500763715dd0 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/6522d59fb7de55ce0f0f285d962243ddffebb01f Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/8ae6c15fc473c9ad03b0173330cce9a092c76154 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/aa69918bd418e700309fdd08509dba324fb24296 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/c741433f6c8dcdecd1d9549d89053761fd1ea413 Types: Patch -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 01, 2026
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/8ae6c15fc473c9ad03b0173330cce9a092c76154 -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 28, 2026
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: openvswitch: vport: fix self-deadlock on release of tunnel ports vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here. However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal. Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released. Added Reference https://git.kernel.org/stable/c/366c482965c673565ecb8bcfb15d5548f13a6a10 Added Reference https://git.kernel.org/stable/c/3df75fff46b1517eb479d8e6b8e3500763715dd0 Added Reference https://git.kernel.org/stable/c/6522d59fb7de55ce0f0f285d962243ddffebb01f Added Reference https://git.kernel.org/stable/c/aa69918bd418e700309fdd08509dba324fb24296 Added Reference https://git.kernel.org/stable/c/c741433f6c8dcdecd1d9549d89053761fd1ea413